home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000529_mleventh@us.oracle.com _Fri Jan 8 21:20:59 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <mleventh@us.oracle.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA02221; Fri, 8 Jan 93 21:20:59 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA03007; Fri, 8 Jan 1993 21:35:57 +0100
  6. Received:  from hqsun4.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
  7.     id AA27399; Fri, 8 Jan 93 12:35:56 PST
  8. Received:  by hqsun4.us.oracle.com (5.59.10/37.3)
  9.     id AA08237; Fri, 8 Jan 93 12:35:54 PST
  10. Message-Id: <9301082035.AA08237@hqsun4.us.oracle.com>
  11. Date: Fri, 8 Jan 93 12:35:54 PST
  12. From: Michael Leventhal <mleventh@us.oracle.com>
  13. To: connolly@pixel.convex.com
  14. Subject: SGML newline processing
  15. Cc: www-talk@nxoc01.cern.ch
  16.  
  17.  
  18. >>>>From what I can tell, a newline is ignored by the SGML parser
  19. >>>if it's right after a start tag or right before an end tag.
  20. >>
  21. >>I haven't been following the discussion closely enough to know
  22. >>if a suggestion for dealing with the problem will be helpful,
  23. >>but...
  24. >>
  25. >>I use the SHORTREF feature to implicitly recognize an EMPTY
  26. >><newline> tag wherever I want newlines after a start tag or
  27. >>right before an end tag to be preserved.  The parser will
  28. >>generate the implicit tags which my processing engine then
  29. >>converts back to actual newlines for output display.
  30. >>
  31. >>Although this seems like a pain I believe the behavior of
  32. >>the parser is logically correct and the only way to be consistent.
  33. >
  34. >Your argument is sound, but we're trying to design a format
  35. >that is defined completely in terms of SGML, but parsed by
  36. >homebrew code.
  37. >
  38. >So the SGML declaration for HTML turns the SHORTTAG feature
  39. >off, saving us some parsing hassles.
  40. >
  41. >If you're using a full-featured SGML parser, you can usually
  42. >tweak the DTD to make the stuff parse how you like through
  43. >shortrefs and the like. But we're using a bare-bones
  44. >SGML parser, so we're just trying to get by without
  45. >conflicting with the standard.
  46. >
  47. >Dan
  48.  
  49. I'm at home with the flu, without my copy of ISO 8879 and I
  50. haven't become one who can quote clause and sub-clause from
  51. memory (yet :-)), but ...
  52.  
  53. SHORTTAG is an optional feature, but SHORTREF is not, since
  54. it is required in the SGML declaration.  I think, according
  55. to the standard, a system which does not support SHORTREF
  56. is not compliant and therefore not even minimum SGML.
  57.  
  58. My solution only requires SHORTREF.  I code:
  59.  
  60. <!ELEMENT    newline    - o        EMPTY>
  61. <!ENTITY    nltag    STARTTAG    "newline">
  62. <!SHORTREF    nlmap    "&#RS;"        nltag>
  63. <!USEMAP    nlmap            (verbatim)>
  64.  
  65. The use of OMITTAG in the newline element is not
  66. necessary.  This code causes the parser to recognize
  67. record starts as newline tas within verbatim tags.
  68. My processor converts the newline tags back to record
  69. starts.
  70.  
  71. Michael Leventhal
  72. Oracle Corporation
  73. mleventh@us.oracle.com
  74.  
  75.  
  76.